home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940126.txt < prev    next >
Internet Message Format  |  1994-11-13  |  22KB
  1. Date: Sat, 23 Apr 94 04:30:19 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #126
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Sat, 23 Apr 94       Volume 94 : Issue  126
  11.  
  12. Today's Topics:
  13.                          486cpu RFI Problems
  14.      ftp mail server source for ax.25 for LINUX operating system?
  15.                    Need Poor Man's Packet Article!
  16.                     On-Air Encryption?.. (2 msgs)
  17.                   Ottawa PI and PI2 driver for Linux
  18.              Running Pactor and GTOR on the Same BBS Port
  19.                               TAPR Radio
  20.                         TI 320C26 DSP Eval Kit
  21.                              Unsubscribe
  22.                                 WEFAX
  23.              Who is ordering GPS receivers from Motorola?
  24.  
  25. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  26. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  27. Problems you can't solve otherwise to brian@ucsd.edu.
  28.  
  29. Archives of past issues of the Ham-Digital Digest are available 
  30. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  31.  
  32. We trust that readers are intelligent enough to realize that all text
  33. herein consists of personal comments and does not represent the official
  34. policies or positions of any party.  Your mileage may vary.  So there.
  35. ----------------------------------------------------------------------
  36.  
  37. Date: Tue, 19 Apr 94 00:26:29 -0400
  38. From: ihnp4.ucsd.edu!swrinde!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!panix!ddsw1!news.kei.com!ub!newserve!sarah!psinntp!psinntp!wlnntp.psi.com!usenet@network.ucsd.edu
  39. Subject: 486cpu RFI Problems
  40. To: ham-digital@ucsd.edu
  41.  
  42. >DATE:   Sun, 17 Apr 1994 13:37:50 GMT
  43. >FROM:   J.D. Cronin <jdc3538@ultb.isc.rit.edu>
  44. >
  45. >In article <2975456864.6.p00123@psilink.com> p00123@psilink.com writes:
  46. >>Probably the biggest factor is to have a computer that is FCC type B 
  47. >>approved for RFI.  Type B is the more stringent standard.
  48. >>
  49. >>Type A is not approved for use in the home or for sale for home use.
  50. >>
  51. >>-Seth
  52. >
  53. >A FCC type approval sticker is meaningless.  I purchased a mailorder
  54. >486 DX2/66 PC, which emitted gobs of RFI from its unshielded
  55. >plastic case, keyboard and monitor.  I complained to the local FCC
  56. >field office, who directed me to the FCC BBS.  (Don't have the
  57. >number handy, call your local field office.)
  58. >
  59. >The registration number was 2 or 3 years old, for a 25 mhz 386
  60. >machine.  It didn't specify the type of cabinet, keyboard or monitor.
  61. >
  62. >Your options are:
  63. >- Purchase reputable brand names.  Look for a decent quality cabinet.
  64. >The plastic front piece should have a metal coating on the inside.
  65. >Also look for spring contacts to ground that metal coating to the rest
  66. >of the case.
  67. >
  68. >- Complain to the FCC.  They probably can't help, but remaining silent
  69. >means you accept the situation as it is.
  70. >
  71. >- Fix the PC yourself.  You have to do this anyway if you're into
  72. >digital modes that require the PC and radio to be in close proximity.
  73. >
  74. >73...Jim
  75. >N2VNO
  76.  
  77. I bought a mail-order 486DX2/50, but I checked first when I ordered it 
  78. about not only the Type-B rating, but the metal case.  From what I could 
  79. determine over the phone, it sounded good.  It was good.  I have the PC 
  80. literally right next to the radios (HF and VHF) and have no problems, 
  81. even on the digital modes.  I did not have to do anything to chase RFI.  
  82. I do have things grounded. 
  83.  
  84. I don't know why anyone would keep a machine that is such a problem, 
  85. unless you have the time and inclination to go through all that...  If 
  86. it's too noisy, send it back.  After all, it's a big investment and 
  87. you're gonna have to live with it.
  88.  
  89. -Seth
  90.  
  91. ------------------------------
  92.  
  93. Date: 20 Apr 94 16:12:47
  94. From: idacrd.ccr-p.ida.org!idacrd!n4hy@uunet.uu.net
  95. Subject: ftp mail server source for ax.25 for LINUX operating system?
  96. To: ham-digital@ucsd.edu
  97.  
  98. The GW4PTS AX.25 Package is available via anonymous ftp on sunacm.swan.ac.uk
  99. in the /pub/Linux/Radio directory.
  100.  
  101. Bob
  102. --
  103. Robert W. McGwier                  | n4hy@ccr-p.ida.org Interests: ham radio,
  104. Center for Communications Research | scouts, astronomy, golf (o yea, & math!)
  105. Princeton, N.J. 08520              | ASM Troop 5700, ACM Pack 53 Hightstown
  106. (609)-279-6240(v) (609)-924-3061(f)| I used to be a Buffalo . . . NE III-120
  107.  
  108. ------------------------------
  109.  
  110. Date: 22 Apr 94 01:54:15 GMT
  111. From: wri!pea@uunet.uu.net
  112. Subject: Need Poor Man's Packet Article!
  113. To: ham-digital@ucsd.edu
  114.  
  115. Does anyone have a copy of the August 1991 73 Magazine
  116. Poor Man's Packet article that ran on pages 8-14?? If
  117. you do, would you please consider faxing me a copy??
  118.  
  119. I have the pmp11 program that I've been tinkering with,
  120. but evidently there is some info in this article I need
  121. to get the program up and running. And, unfortunately,
  122. none of my local libraries have the back issue any longer.
  123.  
  124. My fax number is: 217-359-1761
  125.  
  126. Thank you for your help!
  127.  
  128. Bruce
  129.  
  130. ------------------------------
  131.  
  132. Date: Wed, 20 Apr 1994 18:32:59 GMT
  133. From: ihnp4.ucsd.edu!galaxy.ucr.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com!dfajardo@network.ucsd.edu
  134. Subject: On-Air Encryption?..
  135. To: ham-digital@ucsd.edu
  136.  
  137. Richard Whittaker (rwhittak@docwhitehoorse.doc.ca) wrote:
  138. : Greetings from Whitehorse!..
  139.  
  140. : I've been working with the DOC on a project to use digital radio in disaster
  141. : situations to connect with the Internet via RF links...
  142. <text deleted>
  143. :.... although they raised
  144. : the question of security of the data stream between the remote site (the
  145. : on-scene packet station), and the dish. This link would be made on
  146. : pre-determined "commercial" frequencies, so the question arose as to what
  147. : encryption schemes there were to bolster security of information passing
  148. : over the air... Does any such scheme currently exist, and if so, where would
  149. : one find it and how good is it?.. Any information would be of great
  150. : assistance...
  151.  There is a serious question of what is being protected, and what level
  152. of protection is desired. If you simply dont want the media or the casual
  153. public listening in on city operations, you could use something like
  154. PGP to encrypt each message (I don't know where it is currently archived,
  155. but you could find it easily with GOPHER). A LOT of people on the internet
  156. use it. This would require the originator of the mesage encoding the
  157. message before sending it. 
  158.  
  159.   If your reasons for needing security go beyond this level, then I suspect
  160. the answer is no, and it probably can't be done in a secure fashion
  161. without getting some kind of crypto gear. (Beware of the DES trap; DES
  162. can't be implemented in software and still be in compliance with the
  163. spec - software implementationsof DES are dis-allowed!).
  164.  
  165.   Because Amateur radio is not allowed to use encryption, no development
  166. of hardware for this purpose has been done to the best of my knowledge.
  167.  
  168. Good Luck!
  169.  
  170. Doug Fajardo                         Sysop, LABBS  (CA0199@CAWG.PAR)
  171. dfajardo@netcom.com                  Asst. CAWG Packet Cord. (South)
  172. Eagle 249 (CAP)                      Squadron 35 Com Officer (Pacoima, CA)
  173. WB6KNY (HAM)                         chief Cook and bottle washer, too!
  174. CA0249@CA0199.PACR.CAWG(Packet)      Phone(Voice): (818) 985-841
  175.  
  176. -- 
  177.  
  178. Doug Fajardo                         Sysop, LABBS  (CA0199@CAWG.PAR)
  179. dfajardo@netcom.com                  Asst. CAWG Packet Cord. (South)
  180. Eagle 249 (CAP)                      Squadron 35 Com Officer (Pacoima, CA)
  181. WB6KNY (HAM)                         chief Cook and bottle washer, too!
  182. CA0249@CA0199.PACR.CAWG(Packet)      Phone(Voice): (818) 985-841
  183.  
  184. ------------------------------
  185.  
  186. Date: Tue, 19 Apr 1994 09:26:59 -0400
  187. From: ihnp4.ucsd.edu!swrinde!elroy.jpl.nasa.gov!ncar!asuvax!pitstop.mcd.mot.com!mcdphx!schbbs!mothost!lmpsbbs!NewsWatcher!user@network.ucsd.edu
  188. Subject: On-Air Encryption?..
  189. To: ham-digital@ucsd.edu
  190.  
  191. In article <1994Apr16.173958.2447@clark.dgim.doc.ca>,
  192. rwhittak@docwhitehoorse.doc.ca (Richard Whittaker) wrote:
  193.  
  194. > Greetings from Whitehorse!..
  195. > 
  196. > I've been working with the DOC on a project to use digital radio in disaster
  197. > situations to connect with the Internet via RF links to router stations with
  198. > satellite dishes scattered around the territory. We've demonstrated the
  199. > effectiveness of this system to "the powers that be", although they raised
  200. > the question of security of the data stream between the remote site (the
  201. > on-scene packet station), and the dish. This link would be made on
  202. > pre-determined "commercial" frequencies, so the question arose as to what
  203. > encryption schemes there were to bolster security of information passing
  204. > over the air... Does any such scheme currently exist, and if so, where would
  205. > one find it and how good is it?.. Any information would be of great
  206. > assistance...
  207. > 
  208. > Thanks in advance..
  209. > 
  210. >                     Cheers,
  211. >                     Rich W. 
  212. > --
  213. > Richard Whittaker: Snailmail: 1102 Pine St, Whitehorse YT Y1A 4E8
  214. >   Internet E-Mail: rwhittak@orion.docwhitehorse.doc.ca 
  215. > Geographic Coords: 60 Deg., 45', 53" N., 135 Deg., 7', 17" W. 
  216. >     Amateur Radio: VY1RW, VY1RW@VY1DX, VY1RW@VY1BBS, 145.010 MHz         
  217.  
  218. Once we get beyond the old adage "Never answer a question with another 
  219. question," the first question I ask is the working definition of "security"
  220.  
  221. in line 5 of your query. Are you/they trying only to guarantee message 
  222. integrity (that what is received is what was sent), are they concerned with
  223. authentication (that the entire message was not sent by or received by 
  224. other than the named parties), are they worried about some casual listener
  225. eavesdropping and disclosure to the public, or are they planning to occupy 
  226. Internet/UseNet with militarily classified or secret messaging? The answer 
  227. to this question will at least define the starting point and weed out
  228. methods 
  229. which may be inadequate for the task at hand. 
  230.  
  231. The integrity issue is easily handled by using robust error-checking data 
  232. protocols over the RF channels. This is quite common over commercial HF, 
  233. but don't expect any great throughput on HF, especially with band
  234. conditions 
  235. like they were for the last week! The authentication issue probably should
  236. involve a PGP system. Casual eavesdropping is as much a problem on Internet
  237.  
  238. as it is on HF radio, since anyone can watch all the packets go by if they 
  239. choose. The military security issue and serious encryption of the message
  240. contents can easily be handled using products and techniques currently 
  241. available to those agencies through their normal procurement channels, 
  242. albeit at rather high price tags for the mission you have described.  
  243.  
  244. FLAME ON! - The public and private sources who fund the various national 
  245. relief organizations and their regular operations charter them to deliver
  246. assistance to affected areas in times of need. Relief agencies who are more
  247.  
  248. worried about the encryption of their operational data than getting
  249. emergency 
  250. relief into the field during natural disasters are not providing the
  251. services 
  252. to those who need them, but to themselves instead by diverting funds from
  253. the intended use.
  254.  
  255. -- 
  256. Karl Beckman, P.E.           < STUPIDITY is an elemental force for which >
  257. Motorola Comm - Fixed Data   < no earthquake is a match.  --  Karl Kraus >
  258.  
  259. The statements and opinions expressed here are not those of Motorola Inc.
  260. Motorola paid a marketing firm a huge sum of money to get their opinions;
  261. they have made it clear that they do not wish to share those of employees.
  262.  
  263. Amateur radio WA8NVW @ K8MR.NEOH.USA.NA         NavyMARS VBH @ NOGBN.NOASI
  264.  
  265. ------------------------------
  266.  
  267. Date: Wed, 20 Apr 1994 18:51:55 GMT
  268. From: ihnp4.ucsd.edu!usc!howland.reston.ans.net!cs.utexas.edu!utnut!nott!cunews!news@network.ucsd.edu
  269. Subject: Ottawa PI and PI2 driver for Linux
  270. To: ham-digital@ucsd.edu
  271.  
  272. Announcing the Ottawa PI and PI2 card driver for Linux
  273.  
  274. This driver was designed for use with the AX.25 kernel support from
  275. Alan Cox (version ALPHA 017). It works with kernels supporting NET3
  276. (1.1.5 and higher).  This is the first generally available ALPHA release,
  277. and there are some restrictions, explained in the README.
  278.  
  279. If you are unfamiliar with the Ottawa PI2 synchronous interface card
  280. for amateur radio, send mail with any subject/body to: 
  281.  
  282. pi-info@hydra.carleton.ca
  283.  
  284. The latest driver versions (currently at 0.5 ALPHA) are available
  285. for anonymous ftp from from hydra.carleton.ca, in 
  286.  
  287. /pub/hamradio/packet/tcpip/linux
  288.  
  289. Dave
  290. va3dp
  291.  
  292.  
  293. -- 
  294. Dave Perry                  | Any opinions stated here are mine
  295. dp@hydra.carleton.ca        | and have nothing to do with Carleton University
  296. va3dp@ve3jf.#eon.on.noam   |
  297.  
  298. ------------------------------
  299.  
  300. Date: 22 Apr 94 02:25:49 GMT
  301. From: dog.ee.lbl.gov!agate!howland.reston.ans.net!usenet.ins.cwru.edu!cleveland.Freenet.Edu!ag807@ucbvax.berkeley.edu
  302. Subject: Running Pactor and GTOR on the Same BBS Port
  303. To: ham-digital@ucsd.edu
  304.  
  305.  
  306. SB HF @ WW < NO8M $62887_NO8M
  307. Both Pactor/GTOR On BBS Port (1/2)
  308. R:940420/1604z 62887@NO8M.#NEOH.OH.USA.NA
  309.  
  310.  
  311. RUNNING KAM PACTOR AND GTOR ON THE SAME BBS PORT
  312.  
  313. Real time observations have shown that GTOR is twice as fast as
  314. Pactor on a 80 meter path.  Although we have not been able to check
  315. the performance from different locations (but will from many
  316. locations soon), it is apparent that GTOR will be superior to
  317. Pactor.
  318.  
  319. The availability and popularity of Kantronics TNCs is quite limited
  320. outside of the United States.  BBS support of both Pactor and GTOR
  321. would be an advantage.  In fact, until some further support of GTOR
  322. is made by equipment suppliers shipping outside of the United
  323. States, Pactor has to be supported.(1)(2)
  324.  
  325.      (NOTE 1:  Not all people have Internet or a good VHF support
  326.      network.  I have many DX stations who use the BBS who do not
  327.      have access to the Internet.  Contrary to what some people
  328.      (those who are opposed to HF forwarding) would like you to
  329.      believe, transferring information to South America via VHF
  330.      nodes is not quite possible yet.)
  331.  
  332.      (NOTE 2:  It appears that a number of BBS software packages
  333.      will offer support for GTOR.  None have been released yet
  334.      although one is obviously in beta.)
  335.  
  336. Two KAMs were run in parallel by running the radio port lines in
  337. parallel.  Running these to a Kenwood TS-450 showed that dual
  338. porting will not work in the FSK mode.  The KAM uses a simple
  339. transistor switch to hold the FSK line low unless a toggle is
  340. required.  Rather than reverse engineer that, a change to AFSK was
  341. made.(3)
  342.  
  343.      (NOTE 3:  Two virtually identical HF MSYS BBS systems were
  344.      tested over a long period of time from many locations under
  345.      many conditions.  One system was operated with FSK and the
  346.      other with AFSK.  If there was a difference between FSK and
  347.      AFSK, it was so slight that it was not measurable.  AFSK is
  348.      fine.)
  349.  
  350. Once the radio was run to the two KAMs, an immediate problem
  351. surfaced.  Pactor operation on 3632.1 Mhz. (which is 3630 mark to
  352. a FSK radio) worked fine.  A switch to Pactor showed the radios
  353. were not tuned to the same frequency.
  354.  
  355. /EX
  356. SB HF @ WW < NO8M $62888_NO8M
  357. Both Pactor/GTOR On BBS Port (2/2)
  358. R:940420/1604z 62888@NO8M.#NEOH.OH.USA.NA
  359.  
  360.  
  361. After a bit of experimentation and calculation, we came up with the
  362. following two setup files for the TNCs.
  363.  
  364. For the GTOR KAM:     For the Pactor KAM:
  365.  
  366. <control-c>x          <control-c>x
  367. <control-c>d          <control-c>d
  368. <control-c>d          <control-c>d
  369. pbbs 0                pbbs 0
  370. intf term             intf term
  371. xflow off             xflow off
  372. flow off              flow off
  373. crsup off             crsup off
  374. prekey 0              prekey 0
  375. pthuff on             pthuff on
  376. pmode gtor            pmode pactor
  377. delete 0              delete 0
  378. echo off              echo off
  379. gterrs 80             space 2295
  380. space 2295            mark 2095
  381. mark 2095             shift modem
  382. shift modem           pactor
  383. gtor
  384.  
  385. Now either KAM can seize the radio and respond.
  386.  
  387. THE IDEAL NEXT STEP:
  388.  
  389. It seems like all the pieces are in the KAM to allow it to
  390. recognize a connect from any HF mode.  Whether it has the
  391. horsepower to do that kind of operation may be the problem.  Using
  392. the GSCAN function, an external program could be written to monitor
  393. the port, determine what flavor of connect is coming in, and set
  394. the TNC to that flavor.  It could then assemble packets and feed a
  395. BBS program some sort of Host or KISS mode information.
  396.  
  397. With XT systems going for $100, it may be possible to dedicate such
  398. a box to doing this function.  Use the XT to do the external
  399. codework that the KAM, now used only as a modem, is feeding it. 
  400. The XT would then feed the BBS the resultant frames.
  401.  
  402. Finding someone dedicated to writing such a function is the only
  403. remaining obstacle.
  404.  
  405. 73,
  406. Steve
  407.      NO8M@NO8M.#NEOH.OH.USA.NA
  408.      ag807@cleveland.freenet.edu
  409.  
  410.  
  411. /EX
  412. -- 
  413. 73,
  414. Steve
  415.           ag807@cleveland.freenet.edu
  416.           NO8M@NO8M.#NEOH.OH.USA.NA
  417.  
  418. ------------------------------
  419.  
  420. Date: Wed, 20 Apr 1994 22:22:18 GMT
  421. From: ihnp4.ucsd.edu!swrinde!gatech!howland.reston.ans.net!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!ub!penny!jane!hansen@network.ucsd.edu
  422. Subject: TAPR Radio
  423. To: ham-digital@ucsd.edu
  424.  
  425. Bruce Langos (blangos@wtcp.DaytonOH.NCR.COM) wrote:
  426. : In 1989 the TAPR folks showed a prototype of a 25 watt Radio with
  427. : integrated packet(TNC).  This was shown at the Dayton Hamfest.  Was it 
  428. : every brought to market?  I have been out of packet for many years
  429. : and want to get active again.  
  430.  
  431. No, the project was dropped.
  432.  
  433. ------------------------------
  434.  
  435. Date: 21 Apr 94 16:29:43 GMT
  436. From: dog.ee.lbl.gov!agate!iat.holonet.net!vectorbd!jpll@ucbvax.berkeley.edu
  437. Subject: TI 320C26 DSP Eval Kit
  438. To: ham-digital@ucsd.edu
  439.  
  440. Felton Mitchell (fmitch@netcom.com) wrote:
  441. : Jim Lill (jpll@vectorbd.com) wrote:
  442. : : Has anybody done anything with TI's $99 320C26 Evaluation Kit?
  443.  
  444. : who has the kits? anybody have an 800 number where they can be obtained???
  445.  
  446. most electronic distributors: Arrow, Marshall, etc.
  447.  
  448. -- 
  449. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
  450. -Jim Lill-                                        Vector Board BBS
  451. jpll@vectorbd.com                                 716-544-1863/2645
  452. wa2zkd@wb2psi.#wny.ny.usa.na                      GEnie: ZKD
  453.  
  454. ------------------------------
  455.  
  456. Date: 22 Apr 94 13:15:10 GMT
  457. From: news-mail-gateway@ucsd.edu
  458. Subject: Unsubscribe
  459. To: ham-digital@ucsd.edu
  460.  
  461. Unsubscribe
  462.  
  463. ------------------------------
  464.  
  465. Date: Thu, 21 Apr 1994 15:30:46 GMT
  466. From: swrinde!emory!europa.eng.gtefsd.com!howland.reston.ans.net!math.ohio-state.edu!cyber2.cyberstore.ca!nntp.cs.ubc.ca!alberta!quartz.ucs.ualberta.ca!tribune.usask.ca!kakwa.ucs.@ihnp4.ucsd.edu
  467. Subject: WEFAX
  468. To: ham-digital@ucsd.edu
  469.  
  470. dts@world.std.com (Daniel T Senie) writes:
  471. >     I have heard of people using their HF receivers, to receive the
  472. > WEFAX signal from Spacenet3 T17.  Is anyone out their doing this, or
  473. > could tell me how it is done? 
  474.  
  475. The way this is done is by feeding the baseband video output from
  476. the satellite receiver into the HF receiver.  Note that the HF rcvr
  477. must be set for FM mode.  By tuning across the video signal in the HF
  478. range you will find all kinds of specialty narrowband signals, including
  479. RTTY and WEFAX.  I'm not sure of the exact frequency on Spacenet3 but
  480. perhaps someone else out there does.  Try all the transponders, though.
  481. You'd be amazed at what you might come up with.
  482.  
  483. John Boudreau
  484. ve8ev@inukshuk.gov.nt.ca
  485.  
  486. ------------------------------
  487.  
  488. Date: 21 Apr 1994 08:05:13 -0500
  489. From: ihnp4.ucsd.edu!swrinde!cs.utexas.edu!not-for-mail@network.ucsd.edu
  490. Subject: Who is ordering GPS receivers from Motorola?
  491. To: ham-digital@ucsd.edu
  492.  
  493. Greetings all:
  494.  
  495. A fellow Amateur Radio colleague ( W8RIK )  asked me to post this request for
  496. him .
  497.  
  498. He heard over the Internet that another ham is making a large 
  499. purchase of GPS receivers ( for GPS/APRRS experiments) from 
  500. Motorola.  Does anyone  know this Hams name or how to contact him?
  501.  
  502. He would like to combine the orders for possible savings.
  503. If you have information please contact:
  504.  
  505. Podniesinski@SC3101.Med.Buffalo.Edu
  506.  
  507. Thanks!
  508. N2JRQ
  509.  
  510. ------------------------------
  511.  
  512. Date: Wed, 20 Apr 1994 21:30:31 GMT
  513. From: ihnp4.ucsd.edu!library.ucla.edu!csulb.edu!csus.edu!netcom.com!parker@network.ucsd.edu
  514. To: ham-digital@ucsd.edu
  515.  
  516. References <CoIw0u.2KJ@alsys.com>, <parkerCoJ5z5.67A@netcom.com>, <pineappCoKCL1.L6F@netcom.com>╝
  517. Subject : Re: Internet > Packet gateways??
  518.  
  519. I don't have any idea why it is freezing up. I tried it, and it did the same
  520. for me. The only other thing that I can think of is going through the front
  521. door and giving the command to go into conference mode. I don't know how to 
  522. do that on that particular system though. If it's that important try leaving
  523. a message to the operator to see what's wrong with it. 
  524.  
  525. -- 
  526. -----------------------------------------------------------------------
  527. | Andrew Parker       |       KD6TGM       |       parker@netcom.com  | 
  528. |---------------------------------------------------------------------- 
  529. | This signature is extra lean. It will not contain more than 15% fat.|
  530. -----------------------------------------------------------------------
  531.  
  532. ------------------------------
  533.  
  534. End of Ham-Digital Digest V94 #126
  535. ******************************
  536.